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ABSTRACT 


This thesis examines the planned implementation of the DHS 
and its impact on the Department of Defense (DoD), the Navy 
and, specifically, naval surface ships. The DMS "phased” 
planning will be evaluated, with a concentration on several 
key technological developments that will support the 
modernization of the DoD messaging system. 

The primary link to the DMS will be provided by the Base 
Information Transfer System (BITS) which is the Navy's plan 
for base-level communication system modernization. The BITS 
will network all units attached to the base and include a 
pierslde Interface for ships. An overview of the BITS system 
will be presented with an emphasis on the shipboard interface. 

Several automated shipboard messaging systems will be 
reviewed with the primary attention toward their ability to 
meet future telecomoiunications requirements in terms of degree 
of automation, bandwidth constraints, . security, manning, 
training and design. 
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I. IHTROOUCTIOll 


The Defense Message System (DMS) is a bold attempt to 
bring the Department of Defense (DoD) and its communications 
and message distribution systems into the twenty-first 
century. This communications evolution will rely heavily on 
technologies beinc developed in industry which promise to 
revolutionize both the computer and telecommunications fields 
(i.e., Integrated Services Digital Network (ISDN), fiber optic 
communications. Open Systems Interconnection (OSI), etc.). 

The DMS is merely an aggressive "phased** plan of action 
which will overhaul and combine aging DoD communications 
systems that have suffered in the past from labor-intensive 
procedures, antiquated equipment and the inability to meet 
the tremendous demands that are being placed on them. This 
much needed renovation will be achieved by the complete 
redesigning of a worldwide telecommunications network to 
replace the DoD*s aging Automated Digital Network (AtJTpDIN). 

The AUTODIN is often overtaxed ap it is limited in its 
capacity to expand due to its reliance on outdated, inflexible 
technologies. DMS will be based on highly efficient and 
inexpensive computerized communications networks that provide 
sufficient capacities to meet future DoD messaging demands. 



A. SCOPE 


This thesis will examine, from the messaging system user's 
perspective, the basis of the DMS program as it pertains to 
the DoD in general and tlie Navy specifically. A closely 
Integrated DMS development program requires the evolvement of 
all rhe components of the DoD, from the highest levels in the 
Pentagon down to the "radio shack" on Navy surface ships, to 
circumvent the potential "pitfalls" of technological 
renovation on this scale. 

As DoD-wide telecommxmication innovations are set in 
motion, it is anticipated chat there will be tremendous cost 
savings as a result of reductions in the manual processing 
that has plagued the current messaging system. Along with the 
promise of cost savings is the unfortunate potential for cost 
growth. This cost additive condition might occur as a result 
of needs to provide duplicate communication systems, as the 
technological advances of the "new-age" in digital 
communications find themselves heavily dependent on other, 
simultaneously!developing technologies (i.e., ISDN, 
X.400/X.500, etc.). These "other technologies" will be 
defined in terms of their role in the DMS development and 
their potential to either revolutionize DoD telecommunications 
or hopelessly entangle it due to program delays. 

B. THESIS OUTLINE 

To lay the foundation for the total revamping of the DoO 
messaging system, the DMS eAtablishes a starting point as it 
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maps its way toward an intended target architecture by the 
year 2008. Chapter II vrli outline the justifications and 
objectives of the DMS program as it passes through each phase 
of its metamorphosis. 

Chapter III examines a vital link to the DMS evolution, 
that establishes the groundwork for a user-level connection to 
the worldwide messaging network. This vital link, as it 
pertains. specifically to the Navy, is the 9ase Information 
Transfer System (BITS). BITS is a Navy specific, base 
communication modernization plan, that will prr.vida the vital 
shore-based interface to the DMS network. 

As DMS planners approach the waterfront, the system design 
becomes complicated by the fact that most Navy ships go to sea 
periodically and, therefore, reqviire special consideration. 
The established ship-based ship-to-shore message system 
currently requires two systems, one for in port periods and 
another while at sea. Recent developments in shipboard 
telecommunications will be presented in Chapter IV in an 
attempt to close the gap between shore-based messaging and the 
special requirements for at-sea ubers. 

Chapter V presents a novel twist to the OHS evolutionary 
process as it concludes the thesis by examining the 
ramifications of a rapidly shrinking gap between 
communications and computers in the DoD while reshaping 
shipboard messaging as -The Impact of the Defense Message 
System on the United States Surface Navy* becomes significant. 
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ZZ. AN OVBRVZSW OF THE DEFENSE MESSAGE SYSTEM 

The Defense Message System (OMS) is a Department of 
Defense (DoD) evolutionary implementation plan that is 
intended to provide an integrated messaging system based on 
the concept of standardization and interoperability, »hile 
remaining flexible enough to be responsive to individual 
organizational needs [Ref.ltp 1-4]. The starting point of the 
DMS will be the DoD messaging system as it existed in 
September 1939; and will pass through three major phases 
before it airrives at its expected targat architecture in the 
year 2008. This final architecture will establish a direct 
link between the writer of the message and its intended reader 
in an attempt to speed-up the message communication process 
while reducing costs by taking advantage of modem computer 
and communications systems. 

A. CONDZTZON8 FGR CHANGE 

The problems and costs of the cument messagihg system 
were compounded by the lack of standardization and the heavy 
reliance on manpower-intensive procedures. This slow and 
expensive system suffered from the edssence of a DoC-wide 
communications architecture, as each individual service 
stzruggled to meet operational requirements with a mixed bag of 
antiquated networks, computers, protocols and procedures. 
Adding to the argument for modernisation was the fact that as 
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the computing speed and avail 2 d)le transmission bandwidth 
increased in the marketplace, the costs associated wifth these 
advancements were decreasing rapidly. 

In January 1988, as budgetary constraints became ever more 
prevalent and the existing messaging systems began to reach 
their operating limits, the Assistant Secretary of Defense for 
Command, Control, Communications and Intelligence (ASD/C^I) 
brought together a working group to establish a strategy for 
the development of a DoD-wide system. This working group was 
a joint DoD effort, and by February 1989 they had developed 
and validated a comprehensive planning document known as the 
Multi-command Required Operational Capability for the Defense 
Message System (DMS MROC 3-88). [Ref.lzp. i-i] 

To date, the DMS has been driven by MROC 3-88 tasking, and . 
DoD working groups have since produced Several iterations of 
very extensive planning documents. The remainder of this 
chapter will be dedicated to the examination of the planned 

phases of the DMS, development criteria and key evolutionary 
considerations. 

B. THB 8COPB OF DMS 

The focus of the DMS will concentrate on all hardware, 
software, procedures, standards, facilities and personnel that 
are currently involved in any aspect of the existing DoD 
strategic messaging system, to include both tactical and 



allied interfaces [Ref. l:pp. 1-1 •• 1-2]. The primary DMS 
development efforts will concentrate on a rather extensive set 
of objectives that have been mandated by MROC 3-88 [Ref. 1: 
pp. 1-5 - 1-8]: 

* Connectivity/Intei'operability 

* Guaranteed Delivery/Accountability 

* Timely Delivery 

* Confidentiality/Security 

* Sender Authentication 

* Integrity 

* Survivability 

* Availability/Reliability 

* Ease of Use 

* Message Preparation Support 

Each DMS objective has been mea jred against the service 
quality of the existing system (Baseline system) to ensure 
that there is true progress during the evolutionary process, 
with the underlying goal being to reduce cost and staffing 
requirements [Ref. l:p. 1-7]. 

The DMS will gather under one umbrella all forms of 
narrative messaging systems currently employed in the DoD. 
The term "narrative message" is defined in allied 
communication pviblications as "any thought or idea expressed 
briefly in plain or secret language, prepared in a form 
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suitable for fr&nsmission b** any means for communications.** 
Within the scope of the DMS, of "means of communications" will 
be limited to electronic methods. Under "electronic means", 
there are currently two primary classes of message in use and 
those are: 


* Organizational - These are commonly known as 
"Commanding Officer-to-Commanding Officer" messages. 
Because of their official nature, these messages 
impose critical operational requirements on the 
communication system [Ref. l;p. 1 - 3 ], 

* Individual - This class of message has found an 
electronic foothold with the advent of computer 
networks. It is often in the form of "working" 
communications between DoD personnel and of an 
administrative nature [Ref. 2:pp. lo - 123 . 


The mission of the DMS will be to handle every message 
with an appropriate level of service quality with respect to 
its classification, content and precedence. Currently, 
electronic messages are being handled by the following 
components: 


1; AUTOOIM 


AUTODIN is the primary of the current messaging 
system, and will increasingly be requited to interface vith 
Local Area Networks, (LANs) and Office Automation Systems 
(OASs) as DMS evolves. It is for this reason that DoD has 
selected the X.400 Message Handling System protocol (MHS) as 
the DMT standard. Like the current AUTODIN system, X.400 uses 


the store-and-forward message transfer system. The AUTCOIN 
system is of 1960s vintage and is comprised of many outdated. 


labor-intensive elements, which are the prime target of the 
DMS automation. 

The following is a listing of the major components of 
AUTODIN [Ref. 2:pp. 12-14]: 

* AUTODIN Switching Centers (ASCs;. The 15 ASCs are 
distributed around the world and provide the primary 
store-and-forward message switching, message 
validation, format conversion and routing functions 
[Ref. l:p. 2-1]. 

* Automated Message Processing Exchanges (AMPEs). There 
are over 100 AMPEs and despite the fact that toey all 
perform roughly the same mission they have different 
equipment, procedures and names (i.e., Army's 
Automated Multi-media Exchange (AMME), Navy's Local 
Digital Message Exchange (LDMX) and the Air Force's 
Air Force Automated Message Processing Exchange 
(AFAMPE)) [Ref. 3:p. 59]. 

* Telecommunications Centers (TCCs). There are over 
1000 TCCs and they are the primary input and output 
points of the current AUTODIN messaging system. It is 
these TCCs that are targeted by DMS planners for 
limited messaging system automation, but eventually 
they will be phased out. 

2. E-Mail 

Currently, the Defense Data Network (DDN) is providing 
the backbone for the transportation of the bulk of the data 
being transmitted in the DoD [Ref. 4]. In the near future, 
the DDN will be acting as the primary transportation medium 
for the DMS as the message traffic currently transmitted via 
the AUTODIN network will be migrated to the DDN backbone [Ref. 
5:p. 76]. 


8 




The existing DON backbone systes includes [Ref. 2:p. 

13]; 

* Host computers that support E-Mail 

* On-line directories 

* User terminal access for Personal Computers (PC) 

* DoD Classified Internet: 

- DSNET 1. Defense Secure Network 1 for classified 
General Service (GENSER) Messages. 

- DSNET 2. Worldwide Command and Control System 
(WWMCCS/Classified Messages). 

- DSNET 3. Sensitive Compartmented Information 
(SCI/Classified Messages). 

* DoD Unclassified Internet 

- MILNET 

- ARPANET 

Each equipment that operates on DDN serves a double 
function: first as a general purpose Automatic Data Processing 
(ADP) machine, and secondly as an E-Mail handler, which adds 
to the diversity of the system. (Ref. 2:p. 13) 

C. THE PHASES OP DMS 

The phased i^lementation, as designed by ms planners, is 
intended to deliver the message directly from the writer to 
*’*®d*^ by gradually pushing the so-called AUTODIM "line- 
of-demarcation**, currently located at local TCCs, directly 
into each command. This evolutionary transition will span 
®***^^y y*®ps» beginning with the Baseline system of 1989, 
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and culminating with the Target Architecture by the year 2008. 
Figure 1 summarizes the more significant elements of the DMS 


phased evolution [Ref. 5:p. 9]. 
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Figure l. Stuuaary of DMS Phases 


1. The Baseline (Maval Systems Bmpha&is) 

Figure 2 Illustrates the Baseline Architecture for the 
DMS which has two main elements, the AUTOOIN for 
organizatJ )nal messages, and the DON E-Hall service fcr 
individual messaging [Ref. l:p. 2-2]. Naval organizational 
messaging is supported by the linking of a TCC to the Naval 






Communications Processing and Routing System (NAVCOMPARS), 
which houses the Navy-operated ASCs and provides directory 
services based on the Message Address Directory (MAD). 

Processing a Naval message through the AUTODIN system 
is very laborious and often requires additional processing at 
local TCCs on either an IDMX, a Regional Information Exchange 
Terminal (RIXT ), or if all else fails^ by hand. Once these 
messages arrive at this "line-of-demarkation", the user part 
of the baseline messaging system ends, and,additional manual 
processing and routing must occur before the message reaches 
its intended destination. 

Individual messaging (E-Mail) is provided via the DDN, 
with directory services provided by the Network Information 
Center (NIC). The Navy currently has no applicable policy or 
standards established to cover E-Mail carried over the DDN. 
[Ref. 5;p. 12] 

2. Phase I (1989 - 1994) 

The, first phase emphasizes the automation of TCCs in 
an attempt to reduce manning, while starting the push to 
extend the messaging system to the users [Ref. l:p. 4-1]. To 
aid in this automation, the DoD plans on deploying additional 
transitional components into «ie field, such as AUTODIN 
directory improvements, AUTODIN to DDN Interface (ADI) 
capability, and the transition of DDN E-Mail from the Simple 
Mail Transfer Protocol (SMTP) to X.400 (MBS) [Ref. 6]. 

■ 11 ’ ■ • ^ 
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Finally, during this period, AUTODIN data traffic will begin 
to migrate to the DDN for transport purposes [Ref. 5:p. 32]. 

TCC automation promises significemt cost savings as the 
DoD will be able to plan on reducing certain manning 
requirements of TCC which is characterized by labor intensive 
procedures and the "hard copy message" generations to provide 
Over-the-counter (OTC) services. Currently, there are PC- 
based systems available that will allow users to deliver and 
receive messages via diskette media. (The MTF Editor, a PC- 
based messaging systems, will be covered in Chapter IV.) This 
state of the art computerized automation is the first true 
step toward the intended %rriter-to-reader relationship that 
DMS. planners envisioned. 

Figure 3 depicts the proposed DMS Phase 1 architecture 
which, for the first time, shows an AUTODIK-to-DDN linkage 
[Ref. 7]. Of special noteworthiness is the AUTODIN-DDN 
Interface (ADI) gateway that is outlined in Figure 3 by a 
dotted-line. This gateway has significant security problems 
because it will link, for the first time, the AUTODIN, a 
multi-level secure system, to DDN which does not currently 
meet Defense Coamunications Agency (DCA) message security 
requirements [Ref. 6]. At the end of this phase, AUTODIN and 
DDN E-Mail will continue to act as separate yet interoperable 
systems [Ref. 5:p. 33]. 
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3. PhttS* II (1995 - 2000) 

Figure 4 represents the Phase II architecture which is 
scheduled for completion by the year 2000 [Ref. 7]. During 
this period, tremendous modifications are planned that will 
overhaul DoD messaging such as [Ref.lip. 4-3]: 

* Accelerated phaseout of TCCs. 

* Combining DSNET and MILNET for the purpose of 
inter-base connectivity, which will form the Secure 
Data Network System (SDNS), with data security provided 
by Message Security Protocol (MSP). 

* Base level deployment of the Installation Information 
Transfer Systems (IITS). IITS is one of tiie first key 
elements of the planned Base Information Transfer 

(BITS) and will lead to the complete phaseout 
of TCCs (BITS planning will be examined in Chapter 


* Installation of the Organizational User Agents (OUA) 
and User Agent (UA) as defined by the X.400 protocol 
will shift message transmission and receipt 
responsibilities closer to the user. 

* An Integrated X.4O0 Message Transfer Agent (MTA) and 
X.500 directory services shall be completed. 

* Phaseout AMPEs and ASCs. 

The use of international standards and protocols such 
as Government Open Systems Interconnection Profile (GOSIP) 
will allow tne DoD to take advantage of systems and softwares 
developed by industry, as opposed to having everything 
customized to meet "militarized” specifications (GOSIP and 
X.400 will be discussed in Chapter IV). This new computer and 
communication "systems" development mindset goes hand-in-hand 
vith current DoD purchasing mandates such as Commercial Off— 
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the^Shelf (COTS) buying, Non-Developnantal Items (NDI) and 
Commodity Purchasing (CP). 


CMS PHASE 2 ARCHITECTURE 



Figure 4. DMS Phase 2 (1995 - 2000) 
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By the completion of Phase II the foundations of 
Integrated Digital Network Services (ISDN) shall be laid at 
the base level (BITS). ISDN teclinology, which sports a 
relatively large bandwidth and high data transmission rates, 
will allow the ultimate integration of voice, data, video and 
narrative messaging via one transmission media. However the 
Navy still has ships that deploy and are not able to take 
advantage of the larger ISDN bandwidth using present 
transmission capabilities. It is for this reason that special 
accommodations for fleet interfaces are being planned that 
will modify , the large "overhead" required to transmit X.400 
messages so that "at-sea" messaging will not be all that much 
different from that being performed in port. 

4. Phase III: The Target Architecture (200l - 2008) 

The third and final phase of the I»!S, as depicted in 
Figure 5, actually begins whfen the last AUTODIN ASC is finally 
phased out [Ref. 7]. During this phase, the local and long- 
haul backbone networks wili be fully integrated to form the 
Defense Information System (DIS). The pIS will be an ISDN- 
based global network, of which the DMS segment will continue 
to be the SDNS. Although the development of BITS local loops 
are not actually part of the DMS, their maturity along with 
other I»fS components is essential for the successful 
completion of the Department of the Navy*s (DON) portioh .'>f 
the overall system [Ref. 5:pp. 132-134]. 
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DMS TARGET ARCHITECTURE 



* 2008) 


Figur* 5. DMS Target Architeoture (2001 







Transition frbu AUTOOIN message text format, known as 
U.S. Message Text Format (USMTF), to the X.400-compatible 
Common Message Format (CMF) will put an end to the different 
styles and procedures currently used to generate individual 
and organizational messages [Ref. l:pp. 4-3 - 4-4], 

As more advanced signaling techniques become 
implemented on ships for at-sea users, transmission speeds 
great enough to support X.400 will allow complete DMS 
messaging availability to all DoD components. (At-sea 
messaging will be covered in Chapter IV.) Communications 
planners anticipate that by the year 2008, the DMS, as it is 
intended today, will be a fully operational messaging system 
for the DoD. [Ref. 6] 


D. COMCLUSIOM 

Th«! underlying drive to implement the DMS is the 
requirement to increase the productivity of the DoD messaging 
system while trimming a considerable amount of its operating 
expense., Cost savings and service improvements are always 
noble goals for any management project. A quick review of the 
phase implementation planning of the DMS reveals that while 
the! objectives are aggressive, the use of international 
standards and commercially developed automation communication 
systems and components will go a long way in meeting these 
goals. 
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The only foreseeable drawback to the DMS planning is that 
each phase is closely tied to one another; with multiple and 
overlapping systems, which may create delays. The division 
between phases is blurred by the requirement to be able to 
link the new with the old at all times. The DoD's track 
record for holding onto and extending the service life of 
equipment may become a stumbling block to IMS planners. 
Finally, by placing a heavy reliance on technological 
advancements and "other" independent yet interoperable 
systems' concurrent development (i.e., BITS, ISDN and Fleet 
Interfaces), the intended Target Architecture completion by 
the year 2008 may be a difficult mArk to hit. 
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III. QMS HETWOSX LZIVXMGB TO BASB^LEVBL USERS: BITS 

In the previous chapter, network jargon was used to 
explain the implementation planning of the QMS system, i.e., 
ISON, GOSIP, X.400 and X«500. The scientific definitions 
behind this network terminology are beyond tha scope of this 
thesis. However, a fundemental understanding of concepts 
surrounding these key telecommunication/computer technologies 
are important to the DMS/HiTS user. Therefore, a brief 
overview of several significant network concepts will be 
presented in the following pages. These concepts will serve 
as the building blocks to explain the linkage between QMS and 
the Base Information Transfer System (BITS). 

A. BIT8/0M8 MSTIIORX TSRNZliOLOOy: All OUERVZBW 

The key to the successful implementation of the QMS system 
is to provide a computer-based (digital), high-speed and 
inexpensive transmission medium to transmit large volumes of 
data (messages). in communications, the measure of 
transmission capacity is euphemistically known as "the sise of 
the pipe". In the past,, the DoO had been shackled to a very 
narrow "pipe" in the form cf copper wire-line and radio 
(Microwave Line-of-Sight (LOS), Satellite Communications 
(SATCOMM) or High Frequency (HF)) for its long-haul messaging 
syscp^s, all of which are based on slow and costly analog 
methods for transmission. 



with the advent of high speed, Inexpensive computing, 
coupled with tremendous improvements in digital transmission 
methods and rapidly decreasing prices in fiber optic 
technologies, we now have access to networks that can handle 
transmission rates in the millions of bits per second (MBPS). 
The rub lies in the fact that currently there are smaller 
Local Area Networks (LANs) that can operate at rates around 
100 MBPS, and when they and other communication services 
(voice, image, data and video) demand Integration, the 
networks will require tremendous transmission capacity which 
is not currently available. This is where technologies based 
on Integrated Services Digital Network (ISDN) and the Open 
System Integration Reference Model (OSIRM) begin to bridge the 
gap between the long-haul networks and LANs, or the DMS and 
the BITS. 

1. ISOM 

The BITS architecture will be built around the 

installation of ISDN technologies at the base-level. ISDN is 

A set of telecommunications rules and standards, set by an 

international conuaunications organization kno%m as CCITT. The 

CCITT defines ISDN as [Ref. 8]: 

An ISDN is a network, evolved from the telephony 
Integrated Digital Network, that provides an end-to-end 
digital connectivity, based on CCITT recommendations, 
supporting a wide spectrum of user needs including voice 
and non-voice services. 

End-to-end digital connectivity simply means that if 
you pick up; the phone in your office and make a call, the 
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person on the receiving end will be the recipient of a totally 
digital transmission, all the way down to the wire that 
connects the phone to the wall. This DoD-wide digital 
connectivity is what BITS and the I»fS are banking on to 
PJ^ovide a rapidly maturing worldwide communications backbone. 
ISDN goes well beyond mere voice communications as the CCITT 
definition implies. Ultimately, ISDN will provide digital 
transmission services including data, text, graphics, music, 
video and voice, all of which will be integrated through one 
"pipe." The benefits of ISDN are in the following three areas 
[Ref. 9:p. 743]; 

* International standardized services for world«>wide 
compatibility. 

* User-to-network interface standardization to bring down 
the price of terminal equipment and network equipment, 
while increasing their capabilities. 

* Improved network-to-network communication, to increase 
the throughput of data from end**to-end. 

As ISDN technologies take root around the world, there 
are industry experts that claim that the channel architecture 
currei^tly being developed is too restrictive and will quickly 
become inadequate to, handle the data rates required for such 
things as High Definition Television (HDTV) and 100 MBPS LANS. 
To respond to these critiques, ISDN is looking at its second 
generation, known as Broadband ISDN (B-ISDN), which will 
provide a very large "pipe". [Ref.lO] 
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2 . 081 


Computer and communication technology has evolved 
quickly over the last few decades, and recently the boundaries 
between them have become blurred. Most recently, computer 
bas€^ networks, from the prevalent PCs to the powerful 
mainfreuses, have become the communicator's fare. This rapid 
growth suffered from unregulated growing pains, as different 
networks found it difficult to communicate with each other. 
This untenedsle situation prompted the International Standards 
Organization (ISO) to develop an architecture, knoxm as the 
Open System Interconnection (OSI) Reference Model. This mpdel 
defines data communications standards that will allow 
different networks to interconnect. [Ref. ll:pp. 3-9 - 3-10] 
The OSI Reference Model is a seven-layer architectural 
structure, with each layer having a distinct function. Table 
I is an illustration of the layered structure, with each 
layer's specific functions defined. The concept of the 
layering can be confusing, but the premise behind it is simply 
to provide industry manufacturers with a frame of reference by 
which they can build their systems independently, with certain 
proprietary bells and whistles, while conforming to OSI 
standards to provide interconnection capabilities with other 
systems. [Ref. 9:pp. 15 - 18] 
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TABLE Z. 



3. GOBZP 

The Federal Infomation Processing Standard (FIPS) 146 
is sore coaiBonly know as the Govemaent OSI Profile (GOSIP). 
It was established to provide vendors with a cosnon set of 
data communication protocols so that independently*^eveloped 
systems, produced under GOSIP, can interconnect. As of August 
1990, GOSIP was designated as the official network reference 
model for all OS government agencies. It is felt that by 
establishing. GOSIP as the standard protocol suite, the 
government, and DoD specifically, will lead the way in pushing 
telecommunications toward international network 
interconnectivity, with an added dividend of fair and open 
competition between vendors (Ref. ll:p. 3 -IJ. This DoD-wide 
push for industry acceptance was given a "shot in the arm" 
when, late in 1990, the Navy Issued a Request For Proposal 




(RFP) to the time of $75 Billion for the first GOSIP products 
and services [Ref. 12:pp. 2 and 6]. 

The earliest versions of GOSIP will be dealing with 
the many and varied network architectures currently fielded, 
by the use of a "gateway** between networks. A gateway is a 
networking term used to describe a device (or merely software) 
that is used to link dissinilar or heterogeneous networks at 
the "network layer" of the OSI Reference Model. Its next 
major objective, as relevant to the IXfS, is the transition 
from the Simple Mail Transfer Protocol (SMTP), currently being 
used on the DON, to the X.400-based Message Handling System 
(MHS). [Ref. 13:pp. C-11 - C-13 and C-B-30] 

4. Z.400/Z.500 Protocols 

CCITT has defined the X.400 protocol primarily as a 
Message Handling System (MHS). A MHS is used for transmitting 
electronic messages through commimication systems, end-to-end, 
from the Originator to the reader. The MHS is comprised of 
User Agents (UAs) and Message Transfer Agents (MTAs). A UA 
will compose a message at the originating end of the network, 
and another UA at the receiving end will accept it. Between 
these UAs will be one or more MT^ that will be responsible 
for the transfer of the message from one UA to the other, 
within the ms structure, this UA (originator) to UA 
(receiver) relationship will push the message delivery 
function past the "line of demarkatlon" currently in place in 
the "baseline" AUTODIN system. [Ref. 13:p. C-D-8] 






The CCITT X.5'00 standard defines a directory service 
which will provide a user-friendly nasing and nase-to-address 
sapping functionality [Ref. 12 ;p. C-D-9]. Sisplistically, 
■®«ns that if a DMS systes user would like to send a 
sessage to their college professors. Dr. Suh and Dr. Boger, 
the originating UA merely accesses the X.500 directory and 
addresses this salutation "TO: Dr. Suh and Dr. Boger”, the 
directory will then fill in the actual network address and 
send it on its way. 

This MHS promises to provide data security, message 
•tore-and-forward functions, access to worldwide directories 
of users via the X.500 directory services, and international 
network connectivity under the auspices of the GOSZP protocols 
[Ref. 14; pp 48, 60 and 63]. These protocols are not without 
their faults as they rei^ire a very large "pipe" with fast 
data rates to push a message, wrapped in an X.400 envelope, 
through the system. This tremendous amount of data "overhead" 
is currently one of the major restricting factors to the full 
implementation of the DMS to all users, namely the Naval at- 
sea subscri]3ers [Ref.6]. 

B. BITS ABCHZTBCTUBB 

The DMS requirement for base-level connectivity compelled 
each branch of the DoD to develop ISDN/GOSIP upgrades for all 
facilities. Por the Department of the Navy (DON), the 
responsibility was delegated to the Commander, Naval Computers 
and Telecommunications Command (NCTC) for systems concept 


27 





development, testing and Installation [Ref. 5:p. 110]. From 
the initial planning came the BITS program, under the aegis of 
the Telephone Modernization Plan (TMP). The TMP was a key 
element of the Navy Data Communications Control Architecture 
(NDCCA) which, in 1988, separated Naval.data communications 
into three siib-architectures, of which the base-level (BITS) 
was one [Ref. ll:pp. 3-7 - 3-9]. The underlying motivation 
for NDCCA was that, although most base-level telephone systems 
were adequate, they lacked standardization and were prone to 
costly failures. The goal was to both modernize and institute 
international standards in these new BITS systems, thereby 
taking advantage of ISDN innovations and meeting DoD-directed 
GOSIP requirements. 

1. BITS Objective 

The principle objective of the BITS architecture was 
to provide base-level Integrated network management with 
worldwide interoperability and connectivity. The BITS system 
quickly became locked into the phased implementation planning 
of the DMS architecture since iBfS is one of the services 
available through ISDN modernization. Other BITS objectives 
included: 

* service availability upon demand. 

* Network integrity — as measured by the system's ability 
to send and receive without introducing errors above an 
acceptablf level. 

* System reliability — by the use of redxindant and 
modular systems. This reliability will also be 
facilitated by the implementation of GOSIP standards. 
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* Se^lceabllity — also provided through nodular and 
redundant design. 

The successful fulfillment of the BITS objectives will allow 
each base-level OMS/BITS user access to a stemdardized and 
transparent network that meets all OoO GOSIP requirements, 
while providing ISDN services integrating voice, messaging, 
data, imaging and video. [Ref. 13:pp. c-27 - c-30] 

2. Planaiag Phases 

In December 1986, the Chief of Naval Operations (CNO) 
directed the Naval Data Automation Command (NAVDAC) to develop 
a procedure that could be used as a standard throughout the 
Navy for BITS implementation. This CNO tasking resulted in the 
BITS Requirements Identification and Planning Progrem. This 
central planning effort was instituted to provide for 
standardization and projected cost savings by virtue of their 
market buying leverage. (Ref. I3jp. c-3] 

Under NAVDAC's guidance, each base would develop a 
customized Base Communications Plan (BCP) which would identify 
end account for interbuilding and interactivity 
communications, all the way down tb the waterfront. Once 
completed, the BCP will then' be turned over to >h A NCTC 
commercial buying facility which will then design a BITS 
Modernization Plan. This modernization plan will then be 
developed into a Request Por Proposals (RFPs) to solicit 
contract bids from the private sector. The overall BITS 
planning and development process will pass through the 
following phases: (Ref. I3:pp. c-4 - C-6J 


29 



* Phase I (baseline): Each base identifies a BITS point 
of contact who coordinates all efforts in the 
development of the initial Life Cycle Management (LCM) 
documents. This is the first step in any major DoD 
acquisition program. 

* Phase II: Each base develops a BCP with the assistance 
of NAVDAC under the direction of the base commandino 
officer. 

* Phase III: Technical specifications are drawn to meet 
all DoD requirements with guidance from OPNAVINST 
2800.3. 

* Phase IV: The contracting officer releases the RFP and 
the contract is awarded. 

* Phase V: BITS is installed and tested. 

It is forecasted that the majority of the Naval bases 
will have completed the initial BITS installation sometime 
after 1996 which will meet DrtS phase I mandates; however,.it 
is not expected that this will mean total ISDN conversion. 
ISDN technologies will be Implemented as they become available 
and will be used as the basis for Intrabase data transport 
among DMS processing equipment and ADP equipment, and will 
provide interbase (off base) connectivity. As ISDN matures, 
the Navy plans on its implementation to meet the needs oi 
IBIS'S Phase III high data rate requirements by the year 2Q08. 
[Ref. 13:p. C-66] 

Although BITS is a Navy program, it is also required 
to interface with DoD programs such as the DMS, SDNS and 
finally the DIN. The MIS program requires joint DoD programs 
to monitor its worldwide progress and to insure total 
interoperability. There must be close ti^s between the DoN- 


30 



' '* ,«v • ' \V, S • ••' 


level BITS and the DoD-level DMS; especially when dealing with 
the X.400 MBS and X.500 Directory Service phase**in. 

3. Network Security 

As networks have evolved over the past ten years, so 
have their security problems. Nowhere is the problem of 
network security more critical than in a DoD communication 
system. The protection of military messages (data), 
classified or unclassified, is of the utmost concern for both 
the DMS and BITS designers. The protection of a network goes 
well beyond mere data security as the physical integrity of 
the cabling and equipment loom at the forefront of any DoD 
security officer's planning. 

As a culmination of the combined efforts of private 
industry, academia and the DoD, the National Computer Security 
Center (HCSC) has established a specific set of computer 
system security evaluation criteria in a publication known as 
"the orange book", so named for the color of its cover. The 
were ■ intended to be used as an assessment, tool for 
the evaluation of security attributes of any computer/ 
communication system, and has recently become the standard by 
which security requirements and accreditation have been 
dictated. As Table II illustrates, the NBCS security criteria 
are organized into four divisions ranging from A to D, with A 
being the most secure division [Ref. 15:pp. 260 - 263]. Each 
division is further segmented into classes, and it is by these 
class categories that most systems are evaluated. 
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TABLE II. 

NSCS ••ORANGE BOOK'^ SECURITY CLASSIFICATIONS 



Guided by the NS;;S evaluation criteria, DoN has drawn up 
specific security requirements for all their new computer and 
communications systems [Ref. 13:p. C-)51]: 

* Protection of unclassified yet sensitive information. 

* Data aggregation and inference control, and protection 
of ship movement information. 

* Changes in operational environment/scenario. 

* Separation of classified and unclassified data. 

* Sufficient network controls to meet NSCS 
accreditation. 

* All unclassified networks will meet at least. NSCS Class 
C2 level requirements. 

* All classified networks will meet at least NSCS Class 
B2 level requirements. 

* All gateways will meet at least the NSCS Class B3 
level requirements. 


32 




rhe target security architecture for the BITS system 
is similar in design to the National Security Agency's (NSA) 
proposed SDNS. SDNS is the DoD messaging network scheduled to 
replace DDN. 

The SDNS will use NSA-provided, high*>grade cryptographic 
algorithms for data enc^tion and traffic key generation 
to assure confidentiality of communications. State-of- 
the-art key management techniques will be used to minimize 
the burden associated with generation, distribution, 
accounting, and control of classified key in physical 
form, [Ref. 13:p. c-55] 

The BITS network will be designed around cryptographic 
protection via concepts known as end-to-end encryption (E^) 
and BLACKER. For example, E^ security is similar to the 
enc'-yption methods that protect current messages being 
transmitted from ship-to-shore. If the encrypted message was 
intercepted by some unauthorized source it would be very 
difficult to decipher in a timely fashion. The BLACKER 


program is being developed to support multilevel security 

! 

systems, specifically for networks such as DMS and BITSj. [Ref. 
13:pp. c-51 - C- 56 ] 

4. BITS Arohiteoture 


The foundation of the BITS architecture is b 
several components such as an ISDN-compatible backbon^ 
plant, an ISDN switching complex and network gateways, 
will be used as a Navy-wide standard upgrade to -s 
uniform migration toward the BITS Target Architecture 
The BITS Target Architecture, as illustrated in 
6 , will be configured in such a way that all base eli 
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including ships that are pier-side, will be interconnected to 
an ISDN switching complex and cable plant [Ref. 13:p. C-30]. 
Ftom the switching complex, the BITS network will Interface 
with the DoD }ong-haul communications system (currently DDN 
and AUTCVON). The switching, monitoring ctnd billing of the 
entire system will be controlled by s Network Management 
Center (NMC) which will soon be replacing TCCs as the primary 
communications element at each base. 

The base switch complex will be the key to the BITS 
transition due to the mix of private switches and equipment 
currently in use on many bases. This switching center will be 
the location on base where all services will be integrated and 
distributed for either intrabase (on base) or interbase (off 
base) connectivity. To date, the technology critical to 
achieving a low-cost, efficient integrated switch is limited 
and, therefore, remains as a stumbling block for BITS 
planners. [Ref. 13:p. C-34] 
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Figure C. BITS Arehiteot^re 


The transmission media options that are being 
considered to provide the base backbone cable plant are the 
currently installed copper twisted-pair wiring, a total base, 
retrofit with fiber-optic cabling or a combination of the two. 
These media will be required to meet international ISDN 
standards and will be connected to all users to provide the 
base-wide and DoD-wide network services. 

Pier-side interconnection between a shore-based system 
and a ship at the pier is unique, in that currently telephone 
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service is provided by the base system while messaging (data) 
is not handled via ah intrabase exchange. The fact that ships 
at sea will be using their own means for the transmission of 
both voice and messages further complicates the situation, as 
one communication system is required for ships in port to 
interface with BITS and another is required for those at sea. 
The difference in bandwidth requirements alone is critical to 
both the rafS eind BITS implementation. In the interim, current 
Naval messaging systems will retain most of the responsibility 
for message delivery to ships either at sea or in port. The 
target for a fully operational ISDN pier-side connection will 
be to provide connectivity to the DMS via the BITS with 
sufficient bandwidth for both voice and data services by the 
year 2001 (DMS Phase III). (Ref. 13:p. C-31] 

The Network Management Center (NMC) will be the center 
of the BITS system as it attempts to meet the needs of a 
diverse group of base usars. The interface of the base 
network to the pier-side "lone is like providing flexible 
service capacity to several floating cities whose operating 
schedules make their arrival and departure totally 
unpredictable. This large traffic variation will be managed 
through the NMC automated jsanagement resources and automated 
communications switches. 

C. COMCLUSIOV 

As integrated services become available through BITS 
implementation» the control and management of theso services 
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within each base will becoae acre and acre coaplex. The 
requireaent for the aaintenance of the base's portion of the 
K4S X.400 MHS and X.500 directory, coabined with a full range 
of BITS support functions, will require a fully-staffed and 
autoaated NMC. Currently, there is no NMC-equivalent on aost 
bases, with the only facilities even close in functionality 
being the Naval Telecomaunication Centers (NTCCs) which 
provide AUTODIN connectivity to the base subscribers. Phone 
services are provided by a "aixed-bag'' of Private Branch 
Exchange (PBX) equipaent and wire-line services, which are 
noraally aanaged and aaintained by local telephone coapanies 
telecoaaunications equipaent vendors. It seeas that the 
cost savings derived froa the reduction of aanning and 
antiquated equipaent at base NTCCs, as envisioned by DMS 
planners, will be partially absorbed by the BITS requireaents 
for NMC staffing and network equipaent. 
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ZV. ADTOMATED 8BIPB0ABD 1IB88A0IM0: AM EVOLUTION 

In the previous chapter, it was explained that one of the 
most difficult aspects concerning both the UfS and BITS 
planners was the shipboard interface. While in port, ships 
night be ed^le to link directly into the intended base network 
(BITS). But, when they get underway, there renains a 
transnission capacity problem that cannot quickly be 
dismissed. This chapter will concentrate on the various 
systems that are currently being developed to bridge the gap 
between the manually-intensive shipboard messaging systems 
currently in use and the systems meeting the degree of 
automation required to satisfy DMS architectural demands. 

A. CUESENT 8BZPBOABO NESSAOING 8Y8TEN8 

At present, there are several methods used to process 
messages onboardi ships, ranging from pen-'and-ink message 
drafting to compurer-assisted processing and routing systems. 
Most ships are using two procedures for messaging: a slow ahd 
labor-intensive system while in port and a rudimentary 
computerized system while at. sea. The determination as to 
whether a ship is to have an elaborate computerized messaging 
system is based cn mission requirements and cost, with the 
advent of inexpensive and highly-efficient PCs and "user 
friendly" word processing, software, the gap between the 
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•have's" and "have net's" in autosated sassage processing has 
narrowed. 

1. In Port Messaging 

The vast majority of the fleet still uses pen-and-ink 
message drafting while in port. These drafts are routed 
through the ship's chain-of-command until they reach the 
person with message releasing authority, who is usually the 
commanding officer. By the time the message has been passed 
through this gauntlet, known as "the chop-chain", the draft is 
nearly unintelligible due to the line-outs and re%rrites that 
clutter the page. 

A releasable message will now be passed to the ship's 
Radioman, who will retype it on a standardized DoD form known 
as a "DD-173", with a special Optical Character Readable (OCR) 
^yP* setting. Special processing codes will be assigned, and 
the message will be routed for final release. This labor- 
intensive process usually goes through several iterations due 
to typing or formatting errors before the mestsage leaves the 
ship. Unfortunately, the message is not yet in the 
communication system because it must now be hand-deliver^ to 
the local communication center (HTCC). It is at the NTCC that 
the message will be input into the messaging system via an 
optical scanner. Usually there are errors introduced into 
the system during the scanning process, and these, if not 
caught initially, will slow the system do%instream, as an 
op*bator will have to manually reprocess the message before it 
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reaches Its destination. Once it arrives at the destination 
NTCC, it will be processed emd hand*^arried to its intended 
addressee. 

As desktop cosputers began to appear in the fleet 
during the nid*to-late SOs, the Marine Corps began development 
of message generation software known as Message Text Format 
(MTF) Editor. The MTP Editor is an easy-to-use message 
preparation software package that allows a message drafter to 
create, format and transmit United States Message Text Format 
(USMTF) formatted messages. The MTF Editor is designed to run 
on an IBM compatible PC. With special devices such as a paper 
tape punch or an OCR "daisy-wheel** printer, it can 
significantly reduce the degree of manual processing that was 
required by the old system. [Ref. 5:p. 47] 

The most recent release of MTF Editor includes a 
•floppy" diskette read-and-%rrite capability. , This function 
was developed to meet the DMS Phase I requirement for diskette 
message delivery and receipt at local MTCCs. By delivering 
messages to the MTCC via a diskette, error-prone optical 
scanners will quickly become a thing of the past. This 
message automation capability is very cost efficient because 
it does not require a dedicated computer system to run it. 

An interesting linkage has developed between the BITS 
and DKS systems as a result of the MTF Editor's "next 
generation" which is planning a modem or gateway Interface 
that will allow messages to be sent to and received from the 
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HTCC alactronically, and tharaby aliainating tha 
dalivaxy raquirad in tha prasant systan [Raf. 16]. This 
alactronic dalivary of sassages is an added bonus and was not 
in the original DMS or BITS planning. 

3* Rt-saa Massaging 

Ships at sea are connactad to tha AUTOOIN via several 
Navy-oparatad connunications stations, loiown as MAVCAMS (saa 
Chapter II). This connection is established by tha Naval 
Conputar Processing and Routing System (NAVCOMPARS). 
NAVCONPARS routes massages between the shore-based AUTODIN and 
at-sea subscribers equipped with tha Naval Modular Automated 
Communications Subsystem (NAVMACS) via HP message broadcasts 
(known as a Pull Period Termination) and Pleat Satellite 
Broadcast (PSB) (satellite message transmission for ship at 
sea). The NAVCOMPARS has automated several functions that 
allow efficient delivery and receipt of fleet messages. Among 
the automated functions are: [Ref. 17:pp. 66 - 67 ) 

* Maintaining a real time locator of fleet users. 

* ecreening, and distributing messages for 
both locdl and rasota ai^scribarse 

* Providing termination (receipt) of shin-to-shora 
massaging circuits. 

* Housing the primary interface with tha NAVMACS afloat 

■•••aging system, kriown as the Common User 
‘'I?!*®! Information Exchange System (CUDIX). 

The satellite-based linkage for the ship-to-shore 
messaging is provided by NAVMACS/CUDIXS systems. This 
computerized communications equipment vm developed in 1975 to 
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take advantage of the first fleet cownunication satellites in 
orbit. The CUDIXS receives its input fron the MAVCOMPARS and 
rekeys (retranseits) ell nessages addressed to the fleet at- 
sea users. The NAVMACS is a family of shipboard systems 
ranging from the antiquated V(l) variant to the relatively 
powerful V(5A). Today, over 90% of the fleet has NAVMACS 
installed, with the goal of Navy-wide coverage by the end of 
1992. 

NAVMACS was designed to automate at-sea shipboard 
messaging, and to its credit, most communicators cannot 
imagine being without it. However, NAVMACS is slow and 
expensive compared to today's modem cosqputers. NAVMACS 
planners have been upgrading as many ships as possible with 
later variants as they become available; unfortunately, these 
will not meet the fleet automation needs according to the DMS 
requirements. 

The latest NAVMACS variant, V(5A), is a shipboard 
networked messaging system, with its computerized foundation 
being two UNISYS-built AN/XJYK-44 (nicknamed '•YUK-44'*) 
computers. The AN/UYX-44 is based oh 1975 computer technology 
and, due to its highprice, is limited to such high-value ships 
as aircraft c-.^ triers and large amphibious ships. 
Unfortunately, only the NAVMACS V(5A) is operational during 
normal inport periods (the other NAVMACS variants only operate 
in port for a short period before and after getting underway) 
and must operate with all of its radio transmission and 
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r«cciving •guipnent. This procedure is very cost intensive 
due to the extra aaiming requireaents, and environnentally 
questionable because of the electromagnetic radiation that is 
inherent in radio transmission. Radiomen manning the "Radio- 
Shack” on these ships would be more willing to power-down 
communications gear if there were a system that could 
more efficiently handle their message requirements. 
®**^c*^^**'*^®ly» the V(5A) is not designed for a pier—side 
network interface as required by the BITS architecture, but 
under the Copernicus architecture (discussed later in this 
chapter) there is help coming. [Ref. 18] 

t 

B. HOW DO WB OBT TBBRB ntOM HBSB7 

Designers for contemporary shipboard communication system 
are working on LANs and the new generations of commiinication 
suites to meet the demands of messaging subscribers at-sea, 
and to assure interoperability with the OKS system. 

1. Shipboard LAHt SATBNBT ZX 

One of the major programs that the Navy has been 
on to integrate shipboard cosoiunication services is 
the SAPENET II system. The SAPENET II is the second in the 
series of shipboard network technologies using fiber optics. 
In an attempt to save time and money by. the use of industry- 
developed technologies, its design is based on the American 
National standard Institute (ANSI) standard known as Piber 
Distributed Data Interface (PDDI). 
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The FDDI network standard was chosen because of its 
transmission bandwidth capacity, reliability and cost of 
technology. It is also the standard of choice by BITS network 
designers because FDOI provides redundancy, via dual fiber 
optic rings, and security, since it is not easy to tap into a 
fiber optic cable without disrupting the transmission bit- 
stream [Raf. 19;p. 189]. 

Without getting into an overly complex study of 
network technologies, the following will provide an o'/erview 
of the basic concept behind FDDI. An FDDI-based network uses 
a token-passing dual ring architecture. The token is a unique 
of bits circulating around the network. A nodo (user) 
wishing to transmit on the network must wait until it captures 
the token before transmitting. Once the token is captured, 
the node can start transmitting the message. The token is 
back at the end of the transmission. The message 
travels around the network until it returns back to tha 
originating node. As the message travels around the ring, the 
intended addressee of the message will receive it and pass it 
on its way. This accomplishes two things: first, the fact 
that the token returned to the originator ensures that the 
ring is intact, and secondly, it provides acknowledgement to 
originator. The dual-ring architecture, as depicted in 
Figure 7, provides the redundancy required in any vital 
shipboard communication system [Ref. 20:p. 16]. if a node in 
the ring were to go off-line or the ring were to be severed, 
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the backup ring would allow the rerouting of the message. All 
of these features are transparent to the network user. The 
FDDI system is designed to operate at transmission speeds of 
100 MBPS. [Ref. 19:pp. 187-193] 

Specifically, SAFENET II is ideally suited for the 
DMS/BITS in-port ship-to-pier, and at-sea ship-to-shore 
communication interfaces, because it conforms to the OSI 
standards and avoids the ad hoc retrofitting prevalent in many 
messaging systems. Along with the benefits associated wit^h 
the OSI (or GOSIP) protocols, come the detriments. That is, 
not all GOSIP standards have been clearly defined; amd, though 
private industry is gearing up to provide OSI products, there 
is very little ”on the shelf” at this time. 
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To date, only a prototype of SAFENET exists, as 
developers at the Naval Oceans System Command (NOSC) attempt 
to work out the "bugs” and design a simple and cost effectlye 
method to Install It in the fleet. The present plan of action 
Is to try to sell the Navy on wiring SAFENET directly into new 
construction ships and merely retrofitting a selected number 
of newer ships. This plan is prudent insofaras DMS planning 
documents are not calling for a true shipboard interface until 
the year 2001. [Ref. 20:p. 15] 

2. The Futyre: Copernicus 

In 1543, Copernicus put forth that the sun, and not 
earth, was the center of the.universe. His vision inspired 
the Navy to christen its new communication architecture in his 
neme. The essence of the Copernicus architecture, as it 
applies to the shipboard environment, is to bring multiple 
communication services together into one system. [Ref. 21] 

Currently, there is tremendous competition for the 
limited space in the ship's Radio Shack which is a result of 
the independent equipment that supports a score of tactical 
and strategic commimications systems. Copernicus will striye 
to eliminate the need for customized pieces of equipment, the 
only mission of which is to control but one or two circuits. 
To accomplish this, the Navy must abandon the way it has 
developed communications systemr. in the past, which has 
resulted in delays from five to fifteen yeaj;s (e.g., NAVMACS). 
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The rate of change in technology is already accelerating 
before our eyes. The downside is prograiomatic; the 
generation length for a microcomputer is now less than the 
average tour length of Navy men and women anc. ine-third 
the length of the average acquisition cycle. [Ref. 

21:p. 86] 

In the spring of 1990, the CHO authorized the 
migration of NAVMACS functionality from the current AN/UYK 
series computer systems to commercially-availedsle PCs under 
the Copernicus architecture [Ref. 22]. This decision was 
based on the fact that the NAVMACS program, though adequate 
for the present time, 1 'icked the flexibility to expand to meet 
future shipboard communication needs. 

Table III outlines projected cost savings resulting 
from the replacement of NAVMACS systems with the Navy Standard 
Desktop Tactical Computer 2 (DTC-2). It is assumed that all 
ships including those not currently having the latest variamt 
of the AN/UYK computer are to be upgraded [Refs. 18 and 22]. 
The DTC-2 used in this comparison is a SUN 4/110 workstation 
®goipped with a 300MB hard disk, color ■ monitor. Tempest 
certified high-speed printer, system software and Motorola 
88000 processor [Ref. 22]. 

The potential for cost savings is obvious, but what is 
even more significant is that, wit! the, use of the continually 
evolving PC in the system, NAVMACS can quickly extend itself 
to facilitate both at-sea and in port messaging. An added 
benefit derived from the use of PCs is the fact that they are 
modular and easy to upgrade. The main criticism is that the 
standard "garden variety" PC may not be rugged enough for 
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TABLE III 

HAVHAC8 MIGRATION COMPARISON 


NAVMACS 

SHIP UYK~ 

44 UPGRADE 

DT-2 CONVERSION 

VARIANT 

NUMDEUS ($)Million 


($)Million 

VI 

93 

17.67 


3.72 

V2 

324 

61.56 


12.96 

V3 

74 

14.06 


2.96 

V5 

35 

N/A 


1.4 

V5A 

47 

N/A 


1.88 


SUBTOTAL 

99.29 


2i.92' 


DIFFERENCE 

1 $ 

76,; 

370,000.o6j 

Desk Top 

2 «DT-2) Mod. 

version 

8 $ 

40,000. ea. 

AN/UIK-44 



0 $ 

190,000. ea. 


full-time message processing. Therefore certain components 
must be hardened so as not to break down under heavy use. For 
the most part, these critiques have been answered by the mere 
fact that PCs have been at sea for over ten years and have 
performed adequately thus far. 

Over the past few years, designers at the Space and 
Naval Warfare Systems (SPAWARS) Command have been working on 
ways to integrate PCs onto ships. Thesa efforts were provided 
with extra emphasis recently because of the emergent DMS 
requirements. In an attempt to develop emuiation software 
that would allow the current NAVMACS system to act like a PC 
and simultaneously link into a SAFENET-like LAN,.SPAWARS has 
unwittingly laid the foundation for Copernicus communication 
architecture. This new system has formed its name as an 
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analgaiuation of the English alphabet, and will be known, at 
least for the in ter is, as or the Modernized Naval Front 
End Processor. [Ref. 23] 

The KNFEP program is the epitome of the Copernicus 
vision, as it will consolidate and subsume all of the special 
tactical circuits that each ship must monitor (i.e., OTCIXS, 
TADIXCS, JOTS, FSB, etc.). The circuit that is most important 
(at least to this thesis) is the FSB (Fleet Satellite 
•message" Broadcast). Currently, the FSB is transmitted by 
CUDIXS on shore and received by NAVMACS at sea. Now MNFEP 
will perform all functions previously accomplished by NAVMACS 
and more [Ref. 23]. The front end of this system will receive 
from the various pieces of communications equipment each 
^*ctical circuit which will, in turn, be processed by two DTC“ 
2 computers. The processing will direct each tactical circuit 
tcward its appropriate location via the ship's IAN (SAFENET II 
interface). [Ref. 24] 

Each circuit had previously required its own system of 
equipment to support it, but now only the software within the 
MNFEP will define the prevfc'us syst em, and NAVMACS is no 
different. within MNFEP will exist what will be known as 
NAVMACS II and, instead of having over 30 pieces of NAVMA C S 
specific components, it will share less than 15 with all the 
other tactical circuits. Of these modem components, there 
will be two DTC—2 computers, an optical as well as a magnetic 
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disk storage device, two high-speed shielded printers and a 
LAN transceiver [Ref. 24]. 

The designing concept behind MNFEP is that software 
must be nodular and evolutionary, in that, as each new version 
becomes available, it need only be input into the computer as 
opposed to the old way of redesigning the entire system. The 
modularity ground rule also applies to the system as a whole 
as designers must keep in mind the lessons learned from the 
old, rigid NAVMACS system which was difficult to expand and 
conform to changing requirements. 

Unfortunately, MNFEP and NAVMACS II are in their 
infancy, and most information regarding specific capabilities 
is not yet availedile. The one thing that is apparent, 
however, is that this program is being pushed through the 
acquisition system, and a prototype is being planned for late 
1991, with the first battle group installation and Operational 
Test and Evaluation (OPT&E) to be conducted in mid-1992 [Ref. 
24]. 

One of the major pluses for this Copernicus-sponsored 
project is the fact that the main component of the MNFEP is 
the DTC-2 computer which is being installed on every deploying 
ship since the beginning of the Persian Gulf crisis in late 
1990. By late 1996, it is expected that the entire fleet will 
have an MNFEP system installed. [Ref. 23] 




C. COKCLCSXOH 

Mentioned earlier in thi? chapter was the fact that there 
is a transmission capacity problem that must be overcome 
before the X.400-baged DMS system can be extended to shipboard 
at-rsea users. The problem remains as ftmding in the area of 
satellite transmissions in the remge of Extremely High 
Frequency (EHF) has slowed to a trickle. It is felt that 
recent events in the Middle East have shown how vital high- 
capacity transmission capability is, and that this reality 
will provide the impetus to the search for a larger "pipe" for 
at-sea users. The onslaught of computer technology has 
created tremendous opportunity for the fleet. In vital areas 
such as communications, where previous procedures have left us 
with much to be desired, automation will soon be the rule and 
not the exception. 



y. C0HCLU8Z0M: FUTUBS BFnCTS O? SMS OK TBB KXVY 

As the OoD, and the Navy specifically, xxishes toward a 
potential panacea of performance boosting and cost savings 
through the embrace of message system automation via the DMS 
and BITS programs, it is important to stop and reflect on what 
the potential collateral effects might be. 

A. SnRVZVABZLXTT 

Being able to achieve high system survivability from 
severe damage, whether it be caused by battle at sea or 
natural disaster ashore, is a critical requirement for any 
DoD->wide commxinication system. For the Navy, the past has 
proven that the militarized AN/UYK-44 computer has performed 
admirably with an outstanding record for maintainzd^ility. A 
SPAWABS designer once quipped bhat a ship could take a hit 
from a 16->inch round and keep communicating. But at what 
cost? ' . 

In the past, the preferred yay of designing communication 
systems was to develop each piece of equipment from the ground 
up, component<-by>component, and build it to meet militarized 
specifications to ensure high-reliability. But, would that 
prevent battle damage or provide protection from fire or 
flooding? No, probably not. The next designing plan was to 
physically separate vital and redundant components (that were 
highly militarized, of course!) in different compartments 
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which would ensure survivability by the sheer nuinbers of back¬ 
ups. Again, at what cost? [Ref. 25:pp 226-237] 

A Navy example of the service-wide costs that have been 
incurred are manifested when the NAVMACS program is examined. 
The bottom-line result is a slow and laborious acquisition 
cycle that takes years to field a communications system. This 
has resulted in a system that is so heavily platform-specific 
in its design that it is neither transplantable nor easily 
reconfigured to meet changing requirements. The fact remains 
that computer and network technologies have become so 
powerful, so reliable, so fast, and so inexpensive that the 
survivability considerations spelled out above are easily 
achieved at relatively low costs and in record time. 

B. L00Z8TIC8 C0M8ZDBRATI0N8 

In DoD acquisition cycles, one of the potential downfalls 
for any major program can occur in the area known as 
Integrated Logistical Support (ILS). This is euphemistically 
known as the "catch-all" in program management. ILS tends to 
collect leftover odds-and-ends, system documentation, training 
manning requirements and spare—parts. These 

elements, though vital, are normally considered to be 
low priority items until the programs are about to be fielded. 
Unfortunately, by then, much of the development money is gone 
or has been taken away. 

The result of this kind of program management is that the 
system users often receive equipment they have no idea what to 
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do with. This worst-case situation is exemplified by the 
recent flood of computing devices that suddenly arrived in the 
fleet during the mid-80s. 

When the Desk Top Tactical Computer (OTC-1) first hit the 
fleet, the happy recipients were overjoyed to get these great 
computing machines. Trouble began later when there were no 
standard operating procedures, training programs, spare parts 
or "deck-plate” level expertise to ease these PCs into the 
daily functions of the command. Many man-hours were wasted as 
data files were lost due to operator errors cr system crashes. 
The only plausible answer for this disaster is that the Navy 
was not prepared to purchase these systems and install them in 
the fleet in such a short period of time. 

Now, standard operating procedures have been established, 
training is available and, most importantly, security 
requirements are being addressed at all levels throughout the 
Navy. The question now is "Is it enough?" as the DoD embarks 
on a wholesale automation of systems that was previously 
performed at such rudimentary levels as pen-and-ink message 
drafting. 

1. Maaaiag 

In mid-1990, Vice Admiral J.O. Tuttle, Director, Space 
and Electronic Warfare, the CNO's man in charge of all naval 
C^ development, directed that the first of many 
Interdisciplinary mergers would take place between the Naval 
Data Automation Command (NAVDAC) and the Naval 
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TelecoBBunications Coainand (NAVTELCOMK). This new entity is 
now known as the Naval Conputers and Telecomnunications 
Command (NCTC) and was established to ensure that required 
modernization in Naval telecommunications was 
institutionalized from the top to the bottom. If the cost 
savings conceived by CMS and BITS planners were to be 
realized, not only did the Navy have to update its equipment 
but also its personnel. NCTC, by its position at the top of 
both the Naval communications and computers disciplines, was 
the perfect position to organize this transformation. Since 
■that first merger, several lower level commands have followed 
suit, which has resulted in a little confusion as well as 
tremendous Naval commxuiicaticns opportunities. [Ref. 26:p. 2] 
The implications of the NCTC merger were felt 
throughout the Navy, from Washington, DC to the Naval 
Postgraduate School in Monterey, California. This merging 
policy decision turned out to be a logistical support program 
of massive proportions as service school training commands 
gear-up to cross-train ' Radioman (RM) as Data Processing 
Technicians (DP) and vice versa. On the other end of the 
personnel spectrum, two officers' education programs blended 
into the new sub-specialty defined as Information Systems 
Specialist, which was born from the previous 

Telecommunications and Computer Systems Management fields. 
[Ref. 26:pp. 58-60 and 82] 
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Navy's path toward a complete meirger of computers and 
communication has just begun and there remain many questions 
to be answered. Of the most significant impediments to a 
complete functional merger is the fact that there are vaxying 
degrees of professional pride and colloquial prejudices within 
each group, which could create resistance to this mandated 
change. Adding to the confusion is the fact that not all of 
the Navy will require these interdisciplinary skills right 
away. The reality of the situation is that ships at sea will 
continue to need different telecommunication skills than will 
the communicators ashore, and as long as sailors rotate from 
ship-to-shore periodically, their functional skill base must 
continue to remain very broad. 

2. Training 

To bridge the gap among formal service school 
training, sub-specialty graduate education and the rest of the 
fleet, a Navy-wide computer training and awareness program 
must be instituted. The imderpinnings of any successful 
change is acceptance, and that can be fostered when the stigma 
of computerized "black magic" and "mystery" is dispelled by 
bottom-to-top training. 

Formal training is required for all computer users as 
dictated by Navy regulation. As more and more people become 
aware of their usefulness, compiuters will become commonplace 
in the Navy. The kinds of professional training that will be 
required transcends anything that has gone before it, as the 



Navy (and the DoD) is now attempting not only to march to the 
forefront of telecommunications technology but also to 
actually lead it. 

The skills required to meet future technical needs 
will take a considerable amotint of sophisticated training, and 
to be truly effective, will require a cadre of intelligent 
individuals to form a foundation. Until then^ those that are 
receiving the initial professional training must guard against 
the pitfalls of computer ignorance zmd misuse, as novice 
computer users "hack" their way through operating systems and 
data files, destroying hard work and equipment along the way. 

C. SECURITY 

Security awareness is the thread that binds manning and 
training requirements with respect to ILS programs. As 
computer usage continues to increase, it will become an 
unstoppable part of DMS subscriber's lives. In the future 
both physical and infor^aational security wi^ become all that 
more important. As discussed earlier in this thesis, the DoD 
is spelling out exactly what is expected from industry in 
terms of built-in or trusted computer security systems. 
Unforttuiately, these types of hardware and software security 
restraints are in their infancy and both BITS and the DMS are 
heavily dependent on the rapid maturity. As a result of the 
lack of transparent or Involuntary security restrictions, we 
must rely on self-imposed protection to prevent the 
possibility of accidental or planned insecurities. This level 
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of security can be accomplished by the linking of properly 
skilled, able-bodied personnel and relentless vigilance. 

O. LOOSE BEDS 

In conclusion, it is obvious that there is a lot of work 
ah ead for everyone, from the DHS planners, attempting to 
maintain funding levels and a unity of vision among services, 
to Naval Radioman personnel, who will be seeing not only their 
rating overhauled but also must face the brunt of the momentum 
that has built up behind the demand for automation in the 
Navy. 

This evolutionary telecommunication process has quickly 
become time critical, and any slowdown by the key programs 
(i.e., DMS backbone, BITS pier-side interface, an effective 
ship-shore transmission capability, etc.) will result in 
considerable costs to the system as a whole. This slowdown 
will require redundant communications systems that are capable 
of providing services at both levels of technology, old and 
new. 

Protocol changeovers such as X.400, ISDN and 60SIP will 
require increased capabilities in computing sophistication, 
critical technology maturity emd transmission bandwidth usage. 
These key areas will be the deciding factor as to whether "The 
Impact of the Defense Message System on the United States 
Surface Navy" is a mere bump in the night or a collision at 
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